Frontend API Gateway: GraphQL Federation og Schema Stitching

I en verden av moderne nettapplikasjonsutvikling kan det å håndtere data fra flere kilder være en betydelig utfordring. Etter hvert som applikasjoner blir mer komplekse og tar i bruk mikrotjenestearkitekturer, blir behovet for en enhetlig og effektiv måte å få tilgang til data på avgjørende. En Frontend API Gateway fungerer som et sentralt inngangspunkt for klientapplikasjoner, aggregerer data fra ulike baksystemtjenester og gir en strømlinjeformet opplevelse for både utviklere og sluttbrukere. Dette blogginnlegget utforsker to kraftige teknikker for å bygge en Frontend API Gateway: GraphQL Federation og Schema Stitching.

Hva er en Frontend API Gateway?

En Frontend API Gateway er et arkitekturmønster der en dedikert server fungerer som et mellomledd mellom frontend-klienter (f.eks. nettlesere, mobilapper) og flere baksystemtjenester. Den forenkler datahenting ved å:

• Aggregere data: Kombinere data fra flere kilder til ett enkelt svar.
• Transformere data: Tilpasse dataformater for å passe frontendens behov.
• Abstrahere kompleksitet: Skjule de intrikate detaljene til baksystemtjenestene for klienten.
• Håndheve sikkerhet: Implementere autentiserings- og autorisasjonspolicyer.
• Optimalisere ytelse: Mellomlagre ofte brukte data og redusere antall nettverksforespørsler.

I hovedsak implementerer den Backend for Frontend (BFF)-mønsteret i stor skala og gir frontend-team mer kontroll over API-ene de bruker. I større organisasjoner kan det at frontend-teamet administrerer og kuraterer sine egne API-er føre til raskere levering og redusert avhengighet av backend-team.

Hvorfor bruke GraphQL for en Frontend API Gateway?

GraphQL er et spørrespråk for API-er og en kjøretid for å oppfylle disse spørringene med dine eksisterende data. Det gir flere fordeler sammenlignet med tradisjonelle REST API-er, noe som gjør det godt egnet for å bygge Frontend API Gateways:

• Effektiv datahenting: Klienter ber kun om dataene de trenger, noe som reduserer overhenting (over-fetching) og forbedrer ytelsen.
• Sterk typing: GraphQL-skjemaer definerer datastrukturen, noe som muliggjør bedre verktøy og validering.
• Introspeksjon: Klienter kan oppdage tilgjengelige data og operasjoner gjennom skjemaintrospeksjon.
• Sanntidsmuligheter: GraphQL-abonnementer (subscriptions) muliggjør dataoppdateringer i sanntid.

Ved å utnytte GraphQL kan en Frontend API Gateway tilby et fleksibelt, effektivt og utviklervennlig grensesnitt for å få tilgang til data fra flere baksystemtjenester. Dette står i skarp kontrast til tradisjonelle tilnærminger som bruker flere REST-endepunkter, der hvert enkelt må spørres individuelt og ofte returnerer mer data enn nødvendig.

GraphQL Federation: En distribuert tilnærming

Hva er GraphQL Federation?

GraphQL Federation er en kraftig teknikk for å bygge et distribuert GraphQL API ved å komponere flere GraphQL-tjenester (kalt "subgraphs") til ett enkelt, enhetlig skjema. Hver subgraph er ansvarlig for et spesifikt domene eller en datakilde, og Federation-gatewayen orkestrerer spørringer på tvers av disse subgraphene.

Kjernekonseptet dreier seg om en supergraph, et enkelt, enhetlig GraphQL-skjema som representerer hele API-et. Denne supergraphen bygges ved å komponere mindre GraphQL-skjemaer, kalt subgraphs, der hver representerer en spesifikk mikrotjeneste или datakilde. Federation-gatewayen er ansvarlig for å rute innkommende GraphQL-spørringer til de riktige subgraphene og kombinere resultatene til ett enkelt svar.

Hvordan GraphQL Federation fungerer

1. Definisjon av Subgraph: Hver mikrotjeneste eksponerer et GraphQL API (en subgraph) som definerer egne data og operasjoner. Disse skjemaene inkluderer direktiver som forteller Federation-gatewayen hvordan den skal løse opp typer og felt. Nøkkeldirektiver inkluderer `@key`, `@external` og `@requires`.
2. Komposisjon av Supergraph: Federation-gatewayen (f.eks. Apollo Gateway) henter skjemaene fra hver subgraph og komponerer dem til ett enkelt, enhetlig skjema (supergraphen). Denne prosessen innebærer å løse type- og feltkonflikter og etablere relasjoner mellom typer på tvers av forskjellige subgraphs.
3. Spørringsplanlegging og -utførelse: Når en klient sender en GraphQL-spørring til gatewayen, analyserer gatewayen spørringen og bestemmer hvilke subgraphs som må spørres for å oppfylle forespørselen. Den distribuerer deretter spørringen til de aktuelle subgraphene, samler resultatene og kombinerer dem til ett enkelt svar, som returneres til klienten.

Eksempel: E-handelsplattform med GraphQL Federation

Tenk deg en e-handelsplattform med separate mikrotjenester for produkter, kunder og bestillinger.

• Produkter Subgraph: Håndterer produktinformasjon (navn, beskrivelse, pris osv.).
• Kunder Subgraph: Håndterer kundedata (navn, adresse, e-post osv.).
• Bestillinger Subgraph: Håndterer bestillingsinformasjon (bestillings-ID, kunde-ID, produkt-ID-er, totalbeløp osv.).

Hver subgraph eksponerer et GraphQL API, og Federation-gatewayen komponerer disse API-ene til en enkelt supergraph. En klient kan deretter spørre supergraphen for å hente informasjon om produkter, kunder og bestillinger i en enkelt forespørsel.

For eksempel kan en spørring for å hente en kundes navn og bestillingshistorikk se slik ut:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Federation-gatewayen ville rutet denne spørringen til Kunder- og Bestillinger-subgraphene, hentet de nødvendige dataene og kombinert dem til ett enkelt svar.

Fordeler med GraphQL Federation

• Forenklet datatilgang: Klienter interagerer med ett enkelt GraphQL-endepunkt, uavhengig av de underliggende datakildene.
• Forbedret ytelse: Datahenting optimaliseres ved kun å hente de nødvendige dataene fra hver subgraph.
• Økt skalerbarhet: Hver subgraph kan skaleres uavhengig, noe som gir bedre ressursutnyttelse.
• Desentralisert utvikling: Team kan utvikle og deployere subgraphs uavhengig, noe som fremmer smidighet og innovasjon.
• Skjemastyring (governance): Federation-gatewayen håndhever skjemakonsistens og kompatibilitet på tvers av subgraphs.

Verktøy for GraphQL Federation

• Apollo Federation: En populær åpen kildekode-implementering av GraphQL Federation, som tilbyr en gateway, et skjemaregister og verktøy for å bygge og administrere fødererte GraphQL API-er. Apollo Federation er kjent for sin skalerbarhet og robuste feilhåndtering.
• GraphQL Hive: Dette verktøyet tilbyr skjemaregister og styring for fødererte GraphQL-tjenester, med funksjoner som endringsdeteksjon, bruksanalyse og skjemasjekker. Det forbedrer synligheten og kontrollen over supergraphen.

Schema Stitching: En alternativ tilnærming

Hva er Schema Stitching?

Schema Stitching er en annen teknikk for å kombinere flere GraphQL-skjemaer til ett enkelt, enhetlig skjema. I motsetning til Federation innebærer Schema Stitching vanligvis en mer manuell prosess for å definere hvordan typer og felt fra forskjellige skjemaer er koblet sammen. Mens Federation anses som en mer moderne og robust løsning, kan Schema Stitching være et levedyktig alternativ for enklere bruksområder eller ved migrering fra eksisterende GraphQL API-er.

Hvordan Schema Stitching fungerer

1. Skjemadefinisjon: Hver mikrotjeneste eksponerer et GraphQL API med sitt eget skjema.
2. Stitching-logikk: Et stitching-lag (ofte implementert med biblioteker som GraphQL Tools) definerer hvordan typer og felt fra forskjellige skjemaer er koblet sammen. Dette innebærer å skrive resolver-funksjoner som henter data fra de underliggende tjenestene og mapper dem til det enhetlige skjemaet.
3. Enhetlig skjema: Stitching-laget kombinerer de individuelle skjemaene til ett enkelt, enhetlig skjema som eksponeres for klienten.

Eksempel: Stitching av produkter og anmeldelser

Tenk deg to separate GraphQL-tjenester: en for produkter og en annen for anmeldelser.

• Produkttjeneste: Gir informasjon om produkter (ID, navn, beskrivelse, pris).
• Anmeldelsestjeneste: Gir anmeldelser for produkter (ID, produkt-ID, vurdering, kommentar).

Ved hjelp av Schema Stitching kan du lage et enhetlig skjema som lar klienter hente produktinformasjon og anmeldelser i en enkelt spørring.

Du ville definert en resolver-funksjon i stitching-laget som henter anmeldelser for en gitt produkt-ID fra Anmeldelsestjenesten og legger dem til i Product-typen i det enhetlige skjemaet.

// Example (Conceptual): Stitching logic using GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Define your products schema
const reviewsSchema = ... // Define your reviews schema

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Fetch reviews for the product from the Reviews Service
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Dette eksempelet demonstrerer kjernekonseptet med å sy sammen skjemaer. Legg merke til behovet for egendefinerte resolvere for å hente `reviews`-feltet. Denne ekstra byrden med å kode resolvere for hver relasjon kan gjøre utviklingsprosessen tregere enn ved bruk av Federation.

Fordeler med Schema Stitching

• Enhetlig API: Klienter får tilgang til ett enkelt GraphQL-endepunkt, noe som forenkler datatilgang.
• Inkrementell adopsjon: Schema Stitching kan implementeres trinnvis, slik at du gradvis kan migrere til et enhetlig API.
• Fleksibilitet: Schema Stitching gir mer kontroll over hvordan skjemaer kombineres, slik at du kan tilpasse stitching-logikken for å møte spesifikke behov.

Ulemper med Schema Stitching

• Manuell konfigurasjon: Schema Stitching krever manuell konfigurasjon av stitching-logikken, noe som kan være komplekst og tidkrevende.
• Ytelsesoverhead: Resolver-funksjoner kan introdusere ytelsesoverhead, spesielt hvis de involverer komplekse datatransformasjoner.
• Begrenset skalerbarhet: Schema Stitching kan være vanskeligere å skalere enn Federation, ettersom stitching-logikken vanligvis er sentralisert.
• Skjemaeierskap: Kan føre til tvetydighet rundt skjemaeierskap, spesielt hvis forskjellige team administrerer de sammensydde tjenestene.

Verktøy for Schema Stitching

• GraphQL Tools: Et populært bibliotek for å bygge og manipulere GraphQL-skjemaer, inkludert støtte for Schema Stitching.
• GraphQL Mesh: GraphQL Mesh lar deg bruke GraphQL-spørrespråk for å få tilgang til data fra ulike kilder som REST API-er, databaser og gRPC. Det kan sy sammen disse API-ene til et enhetlig GraphQL-skjema.

GraphQL Federation vs. Schema Stitching: En sammenligning

Både GraphQL Federation og Schema Stitching tilbyr måter å kombinere flere GraphQL-skjemaer til ett enkelt API, men de skiller seg i tilnærming og kapabiliteter.

Funksjon	GraphQL Federation	Schema Stitching
Tilnærming	Distribuert, automatisert komposisjon	Sentralisert, manuell konfigurasjon
Kompleksitet	Lavere kompleksitet for vedlikehold og skalering	Høyere kompleksitet på grunn av manuell resolver-logikk
Skalerbarhet	Designet for storskala, distribuerte systemer	Mindre skalerbart, vanligvis brukt for mindre applikasjoner
Skjemastyring (governance)	Innebygd skjemastyring og validering	Krever manuell skjemahåndtering og koordinering
Verktøy	Sterkt økosystem av verktøy og biblioteker (f.eks. Apollo Federation)	Krever mer tilpassede verktøy og konfigurasjon
Bruksområder	Mikrotjenestearkitekturer, storskala API-er, desentralisert utvikling	Mindre applikasjoner, inkrementell migrering, spesifikke tilpasningskrav

Når du bør bruke GraphQL Federation: Velg Federation når du har en kompleks mikrotjenestearkitektur, trenger å skalere API-et ditt, og ønsker å gi uavhengige team muligheten til å administrere sine egne subgraphs. Det forenkler også skjemahåndtering og -styring.

Når du bør bruke Schema Stitching: Vurder Schema Stitching når du har et enklere API, trenger mer kontroll over stitching-logikken, eller migrerer fra eksisterende GraphQL API-er. Vær imidlertid oppmerksom på de potensielle kompleksitetene og skalerbarhetsbegrensningene.

Implementering av autentisering og autorisasjon

Uavhengig av om du velger GraphQL Federation eller Schema Stitching, er implementering av autentisering og autorisasjon avgjørende for å sikre din Frontend API Gateway. Det er flere tilnærminger du kan ta:

• Autentisering på gateway-nivå: API Gatewayen håndterer autentisering og autorisasjon før den ruter forespørsler til baksystemtjenestene. Denne tilnærmingen sentraliserer sikkerhetslogikken og forenkler baksystemtjenestene. Vanlige metoder inkluderer JWT (JSON Web Token)-validering og OAuth 2.0.
• Autentisering på tjenestenivå: Hver baksystemtjeneste håndterer sin egen autentisering og autorisasjon. Denne tilnærmingen gir mer detaljert kontroll over sikkerheten, men kan være mer kompleks å administrere.
• Hybrid tilnærming: En kombinasjon av autentisering på gateway- og tjenestenivå. Gatewayen håndterer den innledende autentiseringen, og baksystemtjenestene utfører mer detaljerte autorisasjonskontroller.

Eksempel: JWT-autentisering med Apollo Federation

Med Apollo Federation kan du konfigurere gatewayen til å validere JWT-tokens som er inkludert i forespørselens headere. Gatewayen kan deretter sende brukerinformasjonen som er hentet fra tokenet til subgraphene, som kan bruke denne informasjonen til autorisasjon.

// Example (Conceptual): Apollo Gateway configuration with JWT validation
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... your subgraph configurations
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Name of the subgraph
      url,   // URL of the subgraph
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Get the user from the context
    const user = context.user;

    // Add the user's ID to the request headers
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

I dette eksempelet opprettes en tilpasset tjeneste for å modifisere de utgående forespørslene slik at de inkluderer bruker-ID-en som er utledet fra JWT. De underliggende tjenestene kan deretter bruke denne ID-en for autorisasjonskontroller.

Mellomlagringsstrategier for ytelsesoptimalisering

Mellomlagring (caching) er avgjørende for å forbedre ytelsen til en Frontend API Gateway. Ved å mellomlagre ofte brukte data kan du redusere belastningen på baksystemtjenestene og forbedre responstidene for klienter. Her er noen mellomlagringsstrategier:

• HTTP-mellomlagring: Utnytt HTTP-mellomlagringsmekanismer (f.eks. `Cache-Control`-headere) for å mellomlagre svar i nettleseren og mellomliggende proxyer.
• In-memory-mellomlagring: Bruk in-memory-cacher (f.eks. Redis, Memcached) for å mellomlagre ofte brukte data på gatewayen.
• CDN-mellomlagring: Bruk Content Delivery Networks (CDN-er) for å mellomlagre statiske ressurser og API-svar nærmere klienten.
• GraphQL-spørringsmellomlagring: Mellomlagre resultatene av GraphQL-spørringer basert på deres spørringsstreng og variabler. Dette kan være spesielt effektivt for ofte utførte spørringer. Apollo Server tilbyr innebygd støtte for spørringsmellomlagring.

Når du implementerer mellomlagring, bør du vurdere strategier for cache-invalidering for å sikre at klienter mottar oppdaterte data. Vanlige strategier inkluderer:

• Tidsbasert utløp: Sett en fast utløpstid for mellomlagrede data.
• Hendelsesbasert invalidering: Invalider cachen når data endres i baksystemtjenestene. Dette kan oppnås ved hjelp av webhooks eller meldingskøer.

Overvåking og observerbarhet

Overvåking og observerbarhet er avgjørende for å sikre helsen og ytelsen til din Frontend API Gateway. Implementer omfattende overvåking for å spore nøkkelmetrikker som:

• Forespørselslatens: Tiden det tar å behandle en forespørsel.
• Feilrater: Prosentandelen av forespørsler som resulterer i feil.
• Gjennomstrømning: Antallet forespørsler som behandles per tidsenhet.
• Ressursbruk: CPU-, minne- og nettverksbruk for gatewayen og baksystemtjenestene.

Bruk sporing (tracing) for å følge forespørsler mens de flyter gjennom systemet, og identifisere flaskehalser og ytelsesproblemer. Logging gir verdifull innsikt i oppførselen til gatewayen og baksystemtjenestene.

Verktøy for overvåking og observerbarhet inkluderer:

• Prometheus: Et åpen kildekode-system for overvåking og varsling.
• Grafana: Et verktøy for datavisualisering og overvåking.
• Jaeger: Et åpen kildekode-system for distribuert sporing.
• Datadog: En overvåkings- og sikkerhetsplattform for skyapplikasjoner.
• New Relic: En digital intelligensplattform for å overvåke og forbedre programvareytelse.

Ved å implementere robust overvåking og observerbarhet kan du proaktivt identifisere og løse problemer, og dermed sikre påliteligheten og ytelsen til din Frontend API Gateway.

Konklusjon

En Frontend API Gateway bygget med GraphQL Federation eller Schema Stitching kan betydelig forenkle datatilgang, forbedre ytelsen og øke utvikleropplevelsen i moderne nettapplikasjoner. GraphQL Federation gir en kraftig og skalerbar løsning for å komponere distribuerte GraphQL API-er, mens Schema Stitching tilbyr en mer fleksibel tilnærming for å kombinere eksisterende skjemaer. Ved å nøye vurdere de spesifikke kravene til applikasjonen din og avveiningene mellom disse teknikkene, kan du velge den beste tilnærmingen for å bygge en robust og effektiv Frontend API Gateway.

Husk å implementere korrekt autentisering og autorisasjon, mellomlagringsstrategier, samt overvåking og observerbarhet for å sikre gatewayens sikkerhet, ytelse og pålitelighet. Ved å ta i bruk disse beste praksisene kan du frigjøre det fulle potensialet til GraphQL og bygge moderne nettapplikasjoner som leverer eksepsjonelle brukeropplevelser.